home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
BMUG PD-ROM BV3
/
BMUG PD-ROM Version BV3 (CDRM1097900).iso
/
Utilities
/
TidBITs
/
TidBITS 101-125
/
TidBITS#109⁄02-Mar-92.etx
< prev
next >
Wrap
Text File
|
1992-05-27
|
25KB
|
531 lines
TidBITS#109/02-Mar-92
=====================
This week we have news from the virus front, including commentary
from John Norstad of Disinfectant fame, and information about
the new DeskWriter drivers. Read on for details about an
unfortunate conflict between QuickMail and AppleShare 3.0, an
enlightening discussion of patents and copyrights from a
developer of a Mac emulator, and finally an introduction to
VIM and OCE, new messaging technologies worth a close look.
Copyright 1990-1992 Adam & Tonya Engst. Non-profit, non-commercial
publications may reprint articles if full credit is given. Other
publications please contact us. We do not guarantee the accuracy
of articles. Publication, product, and company names may be
registered trademarks of their companies. Disk subscriptions and
back issues are available.
For more information send email to info@tidbits.halcyon.com or
ace@tidbits.halcyon.com -- CIS: 72511,306 -- AOL: Adam Engst
TidBITS -- 9301 Avondale Rd. NE Q1096 -- Redmond, WA 98052 USA
--------------------------------------------------------------
Topics:
MailBITS/02-Mar-92
Printing Notes
More On Viruses
Virus Fighters
QuickMail & AppleShare 3.0
Patents & Copyrights
Messaging Acronyms
Reviews/02-Mar-92
[Archived as /info-mac/digest/tb/tidbits-109.etx; 25K]
MailBITS/02-Mar-92
------------------
We would like to apologize to all of you who received multiple
TidBITS files via the SFU mailing list. We can point the finger of
blame, but not at an identified individual. Apparently, the mailer
problems at SFU were the result of a malicious program started by
some unknown person(s) at SFU. The administrators there are
working on the problems and have managed, we think, to halt the
flow of TidBITS#107. Unfortunately, these problems also showed
them that they don't have the staff to handle such a large mailing
list.
Never fear though, we have everyone's electronic address and have
moved everyone to the LISTSERV at Rice University (many thanks to
Mark Williamson at Rice, who manually added all the SFU
subscribers!). If you were moved over, the LISTSERV doesn't know
your name and will call you "sfu.ca transfer." If you fall in this
category, I strongly recommend that you update your name with the
LISTSERV by sending email to LISTSERV@RICEVM1.RICE.EDU with the
single line in the _body_ of the mailfile:
SUBSCRIBE TIDBITS your full name
Don't worry, sending in two subscription notices will not result
in getting two copies of TidBITS as long you send the SUBSCRIBE
command from the same address that the issue comes to.
We would like to thank both Alvin Khoo for his hard work on the
SFU mailing list and the administrators there for being such
gracious hosts.
Printing Notes
--------------
David Roth writes, "I've been trying to use Professional Composer
on a Mac Plus running System 6.0.5 to generate PostScript files to
be printed on other systems with PostScript printers. When I used
the LaserWriter drivers that come with System 6.0.5, I didn't get
usable PostScript. Acting on a tip from Apple I replaced the
driver on the Mac Plus with the LaserWriter driver from System
7.0.1, and it worked even though I'm only using System 6.0.5! The
best part about it is that I don't have to do command-f or
command-k; I just select PostScript from the LaserWriter driver's
print dialog box instead of letting it default to "Print".
Professional Composer doesn't work on System 7 so upgrading was
out of the question." [Adam: Upgrading to 6.0.8 might have worked
as well, since 6.0.8 is simply 6.0.7 with the System 7 LaserWriter
drivers, but it would have been more work and Professional
Composer might not have worked with 6.0.8 either. It's nice to
know that the System 7 drivers will work with 6.0.5 and may
produce better straight PostScript output files.]
Information from:
David Roth -- david!david@cis.ohio-state.edu
HP Printer Drivers
Ever in search of the truth, or at least what passes for it this
week, I asked a source at Hewlett-Packard about the DeskWriter and
DeskWriter C drivers, since many people have had trouble with
them. Evidently the folks in Vancouver who work on the DeskWriter
drivers have recently made some public statements. Here's the
latest scoop:
* The new DeskWriter and DeskWriter C drivers will be fully System
7 compatible.
* They will support background printing under both System 6 and
System 7.
* The DeskWriter driver will support gray-scale output on a
monochrome DeskWriter.
* They should be available around the end of next month.
Information from:
Marshall Clow -- marshall@sdd.hp.com
More On Viruses
---------------
Murph Sewall wrote to tell us that he talked to both Lloyd
Chambers, author of AutoDoubler, and Greg Friedman, Technical
Director of Aladdin Systems. Murph was concerned that if an
infected application was compressed by either AutoDoubler or
Aladdin's forthcoming SpaceSaver, that perhaps virus checking
programs like Disinfectant would not detect the virus. Both Lloyd
and Greg said that as long as the virus checking program accessed
the infected files through the Resource Manager, they should
successfully detect viruses. So the use of transparent compression
utilities such as AutoDoubler, SpaceSaver, and (presumably) More
Disk Space from Alysis should not impede the functioning of a
virus checking utility. This is not to guarantee that all virus
checkers will detect all infections in any sort of transparently
compressed file, but I know that AutoDoubler and Disinfectant work
fine together, and I imagine that other combinations do as well.
Porting Viruses
Murph continues, "Here's a humorous rumor. A member of our local
user group called yesterday to ask if it was true that the
Michelangelo virus would affect Macs as well as PCs. As a friend
of mine (who works for Apple) says, authors of viruses rarely
publicize what platforms are supported. Porting that sort of code
from one operating system to another is a thankfully daunting
proposition. Still, I may do a full backup on March 5th." [Adam:
This rumor about a Mac version of Michelangelo being a Mac virus
seems to be going around. As far as I know, this is merely a
humorous and incorrect rumor.] [Tonya: It gets less humorous when
you spend a lot of your day explaining how it's only a rumor. ;-)]
Information from:
Murph Sewall -- SEWALL@UCONNVM.UCONN.EDU
Virus Checking Code
Last week I suggested that perhaps Claris could put their
integrity checking code into the public domain so that other
programmers could use it. Several people quickly pointed out the
problem with this idea - publicizing the code would make it easy
for virus authors to circumvent it. In addition, the more
different techniques that people use to prevent viruses from
infecting their programs, the harder it will be for a virus to
pass unnoticed.
Marshall Clow adds, "There are lots of easy things that an app can
do to make life difficult for viruses:
* Mark your resources "protected", especially "CODE 0" and "CODE
1". This makes it more difficult to change them.
* Mark your resource map "read-only". This makes it more difficult
to add or enlarge resources.
* Check the number and sizes of your CODE resources occasionally.
Note that infection need not occur at program startup!
Use your imagination! Be creative! Be a winner like Claris!
P.S. I have no affiliation with Claris."
Information from:
Keith Instone -- instone@euclid.bgsu.edu
Edward Reid -- ed@titipu.meta.com
Marshall Clow -- marshall@sdd.hp.com
Murph Sewall -- SEWALL@UCONNVM.UCONN.EDU
Virus Fighters
--------------
by John Norstad -- j-norstad@nwu.edu
I've been getting a number of thank you notes via private email
and on the newsgroups lately.
Thank you very much. I appreciate your appreciation.
However, I must let everyone know that I'm more than a bit
embarrassed. As the author of Disinfectant, I am in a way just the
most visible tip of a very large iceberg. The rest of the iceberg
deserves just as much credit and thanks as do I. The only problem
is, you don't know who these people are!
I can't list the names of these people, or even the name of our
Internet-based organization. This is not the same group as the
Disinfectant Working Group I mention in my online manual, although
there is quite a bit of overlap between the two groups.
Let me just tell you very briefly what has happened since last
Wednesday morning (19-Feb) concerning this new MBDF virus.
The virus was reported to me, and a copy was sent to me, last
Wednesday morning by a Professor of Mathematics in Wales. I
immediately forwarded his note and the virus to the group.
By Wednesday evening, several members of the group had completely
disassembled, analyzed, and tested the virus. I did NOT do any of
this work!
On Thursday morning, the same professor in Wales sent me a note
saying that he thought he had gotten the virus from sumex-aim. I
checked, and sure enough, the games he mentioned were infected at
sumex.
I again immediately notified our group, which includes the
managers of sumex. The sumex managers started working furiously
checking files, shutting down the archive temporarily and tracing
back the source of the infection. They quickly discovered a trail
leading to Cornell University.
I began working on Disinfectant 2.6. Others in the group worked on
their anti-viral programs, helped prepare public announcements,
and continued to do technical research on the virus. Others in the
group notified the authorities at Cornell and began cooperating on
that front.
To make a long story short, the net result is that:
* Within three days of the discovery of the virus, all of the
major freeware, shareware, and commercial Mac anti-viral tools
were updated to deal with the new virus.
* Two Cornell sophomores have been arrested, arraigned, and are
now in jail, less than six days after discovery of the virus.
[Adam: They are now free on bail, and the FBI has decided not to
investigate or press federal charges.]
This brief historical summary of the events of the past six days
is a wonderful example of the power of the Internet, and is a
wonderful example of the tremendous spirit of cooperation fostered
by the Internet.
At least a dozen people were directly involved in this process. I
was just one of them. I was not even the "leader," just a
participant.
So again, it's embarrassing. The credit should go to the group,
not just to me.
QuickMail & AppleShare 3.0
--------------------------
Oh dear, this will be unpopular. It seems that Apple's recently
released AppleShare Server 3.0 software is incompatible with
versions of CE Software's QuickMail mail server software from
2.2.x up through the current 2.5 and the forthcoming 2.5.1. You
cannot run both AppleShare 3.0 and QuickMail on the same
Macintosh, something which many people have done with previous
versions of AppleShare.
This is related to, but separate from, another incompatibility.
QuickMail server software also conflicts with System 7's Personal
FileSharing, though this conflict is less likely to cause as much
frustration as the conflict with AppleShare Server 3.0. Luckily
the conflicts are only between servers on the same machine, so an
AppleShare client machine will work happily with a QuickMail
server, and a QuickMail client will coexist with an AppleShare
client. It's a silly thought, but I wonder if an AppleShare server
will get along with a QuickMail client? :-)
If you want to run both AppleShare Server 3.0 and QuickMail
server, CE recommends that you do it on two separate Macs. I'm
sure that this won't be entirely feasible for many smaller
organizations, but I know that a user can coexist with QuickMail
server on a personal machine since I've done it on a small scale
(though before I was using System 7 and Personal FileSharing).
That would be a stopgap measure until CE and Apple fix the
incompatibility.
CE is working hard to fix this problem, but unfortunately, it's
not a trivial fix. Apple and CE are evaluating changes to their
server software so that the two can coexist better in the future.
You can be sure that both companies are interested in better
compatibility, since QuickMail is the most popular Macintosh email
software, and I'm willing to bet that the combination of
AppleShare 3.0 and System 7's FileSharing holds the lion's share
of Macintosh networking software in use.
Information from:
Christian F. Gurney, Manager of Technical Support, CE Software
Mark H. Anbinder -- mha@baka.ithaca.ny.us
Patents & Copyrights
--------------------
by Clifford T. Matthews -- iclone!ctm@unmvax.cs.unm.edu
Abacus R&D, Inc.
(Disclaimer: I am biased since my company developed and markets
"ROMlib" and "Executor," two products that predate Quorum's
similar Latitude and Equal. None of our or Quorum's products
require the user to copy the Apple ROMs or System File. Please
note that currently our products are only supported on NeXT
computers, but this will change within six months.)
Adam C. Engst writes in TidBITS#108:
> Finally, since Quorum based the display parts of Latitude
> on Adobe's Display PostScript, there is no conflict with
> Apple's patented QuickDraw software (which is why most
> other emulators have required that you find some Mac
> ROMs to pop in).
US Patent #4,622,545 covers Apple's region code. If you take the
claims in that patent (there are 35) at face value, then _anyone_
that attempts to be compatible with the Mac will either have to
get permission to use the patented technology or be in violation
of the patent. It is an absurd patent that for all practical
purposes locks up the data structure itself. So, even though
Quorum doesn't use regions for most of its work, since it has the
ability to read regions when processing PICTs it is in violation
(assuming there's no secret agreement between Apple and Quorum).
Apple has done similar things with their HFS structure in England.
They have a patent there, which if taken at face value, prohibits
anyone from reading or writing HFS compatible disks. [Adam: Note
that several companies including Hydra (Mac emulator on a PC) and
Gadgets By Small (Mac emulator on an Atari ST) already market
products that do this.]
I believe there are two real reasons that other emulators require
Mac ROMs.
* It is much easier to use someone else's code than to rewrite the
code yourself. Whether or not you choose a different "look and
feel," as Quorum does, or you intentionally do exactly what the
application code is asking for, as we do, rewriting the ROMs is a
major achievement. It is especially difficult since the Mac OS is
a hodgepodge of code that has several side-effects that an
emulator must duplicate if it expects to run real world
applications.
* The second reason has to do with "look and feel" copyright (not
patent) issues. The basic claim is that by using legitimate ROMs,
the right to the look and feel is transferred with the ROMs. Apple
hasn't challenged the rights of people who have acquired Mac ROMs
to use them in other devices (although there was a challenge
related to who can sell Mac ROMs). The implications here are
significant. Apple is in effect admitting that they don't totally
own the rights to the "look and feel" or else they would be able
to shut down these other companies. In fact, if Apple had made an
explicit claim for the "look and feel" in the early days of
development, warning developers that "... the look and feel of
your product ... is commingled with the look and feel of our
product ... and hence can't be used on any platform other than
what we specify ..." then, perhaps, they would have the right not
only to attack clone makers but also companies that hack up Macs
and put them in boxes that Apple doesn't like. Of course if Apple
had done that in the early days, these policies would have scared
numerous developers away, perhaps causing the Mac to fail.
Copyright and patent issues are very difficult indeed. There have
been exceedingly few cases that have actually gone to trial and
none of them addressed the specific issue of whether or not the
look and feel of an application belongs to the application writer
or the operating system vendor. I bring this up to point out that
Quorum may not be in the clear as much as the original article
implies and to reassure people who are interested in our
technology that we are equally aware of the legal implications of
what we're doing and that we too believe we're totally in the
clear. Quorum has chosen to alter the "look and feel" of
applications built with Latitude or run under Equal; we have
chosen not to. Films that were shot in black and white can now be
"colorized," and some people prefer colorized films. However
others prefer to be true to the original creation of the
producers, directors and cinematographers. When it comes to
computer software there are more concerns than those aesthetic;
there are manuals to rewrite and people to retrain. The nineties
are going to be interesting.
Messaging Acronyms
------------------
I have some new acronyms for you - VIM and OCE. Only time will
tell if these particular acronyms will be with us in the future,
but VIM and OCE are certainly worth some thought. VIM, or Vendor
Independent Messaging, is a new standard programming interface
proposed by Apple, Lotus, and Novell, and supported by Borland and
IBM. The idea behind VIM, as far as I can tell, is that anyone
will be able to write an application requiring cross platform
messaging services using VIM, and application will then be able to
talk to all other VIM-aware applications (you've heard of System
7-savvy - perhaps this should be VIM-vigorous?).
VIM is by no means a new idea, and in fact Apple and Lotus tried
the same thing earlier under a different acronym, OMI, or Open
Messaging Interface. Rule #1 of marketing initially unpopular
products: change the name. If it's an acronym, probably nobody
will even notice the difference. IBM didn't change the name of
OS/2 and may have to drop a couple extra million dollars into
marketing it as a result.
Back to the discussion at hand. OMI suffered from the fact that no
one much liked it, especially Novell, which carries a lot of
weight in the LAN community. Everyone likes the idea of VIM
because it's becoming even more obvious that hardware and software
from different vendors needs to communicate better. Of course,
you'll notice that the companies in question are all members of
the Anti-Microsoft Fan Club for various reasons, which may account
for why Lotus and Borland are consenting to be seen together in
the same press release. I suspect that OMI was a little too early
to gather the support it needed. Now that everyone is a bit more
worried about Microsoft's intentions for the industry, not to
mention the way those intentions are being carried out, even Lotus
and Borland might feel a bit more kindly toward each other.
VIM may end up helping with cross-platform messaging, but Apple
has its own in-platform messaging scheme now too, called OCE, or
Open Collaboration Environment. OCE will add a pleasant front end
to what is currently a bit of a user interface nightmare -
connecting to network services and working with them. Even basic
email programs are often a pain to use and aren't as integrated
with the rest of the operating system as many users would like.
OCE should help a lot in that respect, providing a Mailbox icon
and a World icon right on the Mac desktop and plenty of behind the
scenes technology as well.
Integrated email
The Mailbox icon will open to a window displaying incoming mail,
whereas outgoing mail will be handled partly through drag & drop
on the Mailbox icon (presumably for pre-addressed files) and
partly through integration with applications. Some people on ZMAC
were discussing the possibility of using this sort of capability
to mail a file to a coworker and then have changes to that file
automatically updated in the remote copy through the Edition
Manager, a capability that could be very popular in a publishing
workgroup, for instance.
I'm especially interested in the concatenation of all my mail
services into a single mail environment. Quite frankly, I'm tired
of checking email on five different services, each with a
completely different interface. I'm still envious of CE's Don
Brown though, since he has more email addresses on his business
card than I had thought possible. He who dies with the most
addresses wins, but no one will care once OCE is out and used.
Incidently, one of the electronic islands, America Online, is busy
at work on a bridge to the Internet. Look for it sometime this
spring or summer.
Network services on the desktop
The World icon will help bring everything together by providing a
single location for all network services and devices, so you don't
have to search about in the Chooser. Aside from servers,
databases, and network devices such as printers and fax modems,
users and groups will be represented in the World window, so
sending a file or email to someone remotely could be as easy as
dropping it on their icon. I'm sure there will be other methods of
sending information as well, since drag & drop, as nice as it can
be, is not the ultimate mail interface.
Data Wrappers
Of course, once Apple brings all this wonderful network stuff out
of the closet (does that mean all of us who live on the nets have
to come out too?), great confusion will reign due to the massive
amount of information suddenly available. Luckily for us, Apple
has considered this problem and has come up with the idea of the
data wrapper, a layer of indentifying information wrapped around a
data file. You'll be able to add keywords, events (some
interesting functions could come from this), and even your own
customized fields to the data wrappers, which will then allow you
to filter your files based on the wrapper criteria. I hope Apple
will also provide some tools for automatically creating data
wrappers and filtering the data in them, since I've found such
keywording too much trouble in the past. How many people really
enter summary information for every one of their Word 5 files?
Data Worries
Some third parties like CE Software are concerned that OCE will
remove much of the need for their products. After all, if email is
integrated into the Finder and major applications, why bother to
use QuickMail? I imagine that Apple's tools will fall short of the
sophistication needed by power users and large organizations.
Apple often targets its software at a common denominator of user,
thus increasing the available market and leaving room for third
parties to provide enhancements at the same time. I see no reason
that OCE will be different, and even if programs like QuickMail do
become redundant, I'm sure that CE will capitalize on its
knowledge of email applications and uses to retain a leadership
role in the email market. If nothing else, someone is going to
have to write gateways for OCE, and nothing has more gateways than
QuickMail.
It is nice to see Apple working on this kind of stuff for the Mac
since operating systems of the future will have to be aware of
more than just the machine they live on, and I think Apple
realizes that network awareness is only half the battle. The other
half is making those services easily accessible and useful,
something which Apple is generally, though not universally, good
at. I'm all in favor of making email easier, so I'm looking
forward to whatever Apple does come up with.
Information from:
Mark H. Anbinder -- mha@baka.ithaca.ny.us
Apple propaganda
Related articles:
MacWEEK -- 10-Feb-92, Vol. 6, #6, pg. 1
Communications Week -- 10-Feb-92, #389, pg. 1
Reviews/02-Mar-92
-----------------
* MacWEEK
Muse -- pg. 37
MacLinkPlus 6.0 -- pg. 38
On Cue II -- pg. 39
VideoSpigot -- pg. 40
References:
MacWEEK -- 24-Feb-92, Vol. 6, #8
..
This text is wrapped as a setext. For more information send email
with the single word "setext" (no quotes) in the Subject: line to
<fileserver@tidbits.uucp>. A file will be returned promptly.